10장. 콘텍스트 도마 관리하기

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 10장 (pp. 202~219). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

AI 어시스턴트가 들고 다니는 디지털 클립보드 — 콘텍스트 윈도 — 에 무엇을 올리고 언제 비울지를 능숙하게 다루는 것이, 저자들이 바이브 코딩에서 가장 중요한 기술 중 하나로 꼽는 콘텍스트 엔지니어링이다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 토큰과 콘텍스트 윈도의 관계를 설명하고, 소형 모델과 프런티어 모델의 콘텍스트 윈도 규모 차이를 구분한다.
• 대화가 길어질수록 누적 토큰 비용이 2차함수적으로 증가하는 이유를 설명한다.
• 콘텍스트 포화가 성능을 절벽처럼 무너뜨리는 현상과 그 경험적 임계치를 식별한다.
• 집중형 콘텍스트와 포괄형 콘텍스트 전략을 구분하고, 작업 성격에 맞게 선택한다.
• 대규모 코드베이스를 다룰 때 요약 문서·RAG·에이전트 기반 검색의 트레이드오프를 비교한다.

전체 흐름도

              §1  콘텍스트 엔지니어링 — 이 장이 다룰 것
        대화·데이터가 들어갈 공간을 관리하는 기술
                          │
                          ▼
              §2  AI 수셰프의 클립보드 — 콘텍스트 윈도와 토큰
   1토큰≈4글자 · 소형 모델 512~4000토큰 vs 프런티어 모델 20만~100만토큰
                          │
                          ▼
              §3  콘텍스트 이해하기 — 상태 없는 대화, 2차함수적 비용
      메시지 배열이 매번 통째로 재전송 → 누적 비용은 n(n+1)/2
                          │
                          ▼
              §4  콘텍스트 포화의 위험성
      공식 최대 용량과 무관하게 약 3000토큰 부근부터 절벽처럼 붕괴
                          │
                          ▼
              §5  출력 콘텍스트 윈도의 한계
      입력과 별개로, 한 번에 돌려받을 수 있는 양도 제한된다
                          │
                          ▼
              §6  클립보드에 무엇을 올릴 것인가 — 콘텍스트가 왕이다
      전체 소스 파일·에러 메시지·테스트 케이스·MCP 연결
                          │
                          ▼
              §7  집중형 콘텍스트 ↔ 포괄형 콘텍스트
      리프 노드 작업엔 최소 정보, 전체 작업 그래프엔 방대한 배경
                          │
                          ▼
              §8  어떤 전략을 사용할까 — 대규모 코드베이스
      요약 문서(클리프노트) · RAG · 에이전트 기반 검색 — 정답은 실험 중
                          │
                          ▼
              §9  결론 — 다섯 가지 핵심 실천 사항
      주시 · 조기 인지 · 전략 구분 · 도구 활용 · 직감 신뢰 → 11장으로

0. 용어 사전

참고 — 위쪽 4개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 해당 장을 먼저 보라.

1. 콘텍스트 엔지니어링 — 이 장이 다룰 것

이 장은 바이브 코딩에서 가장 중요한 기술 중 하나를 다룬다 — 대화와 데이터가 들어갈 공간을 관리하는 방법, 즉 콘텍스트 엔지니어링이다. AI와 얼마나 효과적으로 협업하느냐는 결국 AI와 대화할 때 흐르는 정보를 얼마나 능숙하게 관리하느냐에 달려 있다.

바이브 코더가 작업 공간을 관리하는 방법과, 스크랩북 같은 역할을 하는 콘텍스트 윈도를 어떻게 다루는지가 이 장의 핵심이다. 콘텍스트의 일부만 선택해야 할 때와, 가지고 있는 모든 정보를 윈도에 넣어야 할 때를 구분하는 감각을 기르는 것이 목표다.

콘텍스트 관리를 제대로 하지 못하면, 방금 전까지 지시를 자신 있게 따르던 AI 어시스턴트가 중요한 세부 사항을 잊어버리거나, 이상한 지름길을 택하거나, 앞뒤가 맞지 않는 말을 하기 시작한다. 이 장이 다루는 실용적 기법은 다음과 같다 — ① AI가 핵심 정보를 '잊어버리게' 만드는 콘텍스트 과부하를 방지하는 방법 ② 집중형 콘텍스트와 포괄형 콘텍스트를 전략적으로 쓰는 방법 ③ 콘텍스트에 절대 다 담을 수 없는 코드베이스와 효과적으로 작업하는 방법 ④ 기존 대화를 이어갈 때와 새로 시작해야 할 때를 구분하는 방법. 함수를 디버깅하든 시스템을 설계하든, AI에게 적절한 시점에 적절한 정보를 주는 것은 바이브 코더의 핵심 기술이다.

2. AI 수셰프의 클립보드 — 콘텍스트 윈도와 토큰

AI 어시스턴트는 자신이 무엇을 하고 있는지 추적하기 위해 디지털 클립보드를 하나씩 들고 다닌다. 지시 사항, 자신이 받은 명령, 진행 상황, 앞으로 적용하려는 변경 사항까지 전부 이 클립보드에 올라간다. 클립보드에 올라가 있지 않은 작업은 결코 수행되지 않는다. 그래서 지금 클립보드에 무엇이 올라가 있는지를 주의 깊게 살펴야, 수셰프가 과부하 상태인지·정말로 올바른 일에 집중하고 있는지를 판단할 수 있다.

업계에서는 이 클립보드를 콘텍스트 윈도라 부른다. 실제 사무용 클립보드나 스크랩북처럼, 하나의 긴 페이지 위에 텍스트·이미지·오디오 등 여러 데이터가 담긴다. 대화를 거치며 생성된 데이터, 규칙, 지금까지의 대화 내용 전체가 여기에 들어간다.

토큰과 글자 수. 콘텍스트 윈도의 용량은 담을 수 있는 단어 개수로 표현되는데, 책의 길이를 단어 수로 재는 것과 같은 방식이다. 다만 책이 쓰는 단위는 '워드'(약 다섯 글자)이고, AI 모델은 이를 토큰이라 부른다. 모델 제공자는 질의가 소비·생성하는 토큰 수로 비용을 청구하며, 흔히 쓰는 경험칙은 1토큰≈네 글자다(정확하지는 않지만 대략적인 감을 잡기엔 충분하다). 토큰과 토큰 어휘 집합(모델이 쓰는 토큰의 총 가짓수, 예: 라마 2 약 3만 2000개 vs GPT-4o 20만 개 이상)은 서로 다른 개념이다.

모델마다 다른 규모. 질문 분류·의도 탐지 같은 단순 작업을 하는 구글 BERT 계열 같은 소형 모델은 512~4000토큰(약 1000~2만 자) 정도의 콘텍스트 윈도만 갖는다. 반면 최신 프런티어 모델은 20만~100만 토큰(4~5메가바이트)에 달하는 거대한 콘텍스트 윈도를 갖고 있고, 라마 4처럼 1000만 토큰을 자랑하는 모델도 있다. 콘텍스트 윈도 크기 경쟁은 일종의 클립보드 크기 경쟁이며, 이론적으로는 윈도가 클수록 더 큰 작업을 성공적으로 수행할 수 있다 — 다만 콘텍스트가 채워질수록 비용은 비싸지고 에러 가능성도 커진다.

수치로 감을 잡아 보자. 저자들의 분석에 따르면 전 세계 깃 저장소의 약 80%는 50만 토큰 콘텍스트 윈도 안에 들어간다 — 상당수 코드베이스를 통째로 AI에게 전달하는 것이 이론적으로는 가능하다는 뜻이다. GitIngest·Repomix·files-to-prompt 같은 도구가 저장소를 LLM이 소화할 수 있는 텍스트 문자열로 바꿔 주지만, 할 수 있다고 해서 항상 그래야 하는 것은 아니다.

참고 — 그림 10.1, 콘텍스트 윈도가 채워지는 순서. 콘텍스트 윈도는 이것저것을 집어넣을수록 선형적으로 채워지는 스크랩북이다. 가장 먼저 시스템 프롬프트(핵심 지침·규칙·기능)가 들어간다 — 대개 모델 제공자(앤트로픽·구글·OpenAI 등)가 미리 채워 두므로, 아무것도 하지 않아도 공간 일부는 이미 차 있다. 그다음 사용자가 정의한 규칙과 초기 프롬프트, 이어서 저장소 파일·코드 스니펫 같은 코드 콘텍스트, 이미지·PDF 같은 미디어 및 문서, 마지막으로 대화 기록(이전 턴)이 쌓인다. 예시로 든 12,000토큰 규모의 윈도에서는 이 순서대로 채워지고 남는 공간이 새 입력과 출력 예약에 쓰인다.

3. 콘텍스트 이해하기 — 상태 없는 대화와 2차함수적 비용

모든 AI와의 상호작용은 누적되어 저장된다. LLM에게 메시지를 보내면 방금 입력한 프롬프트만 전송되는 게 아니다 — 시스템 지침, 모든 대화 내역과 콘텍스트, 방금 입력한 프롬프트까지 전부 함께 전달된다. 즉 콘텍스트 윈도의 내용은 매번 다시 누적되어 전송된다. 2025년 기준 대부분의 LLM은 상태 비저장(stateless) 구조를 택하고 있어서, 대화를 할 때마다 이전 콘텍스트가 다시 전송된다 — 이는 성능과 비용에 큰 영향을 준다.

채팅이 API 차원에서 어떻게 구현되는지 보면 이 구조가 분명해진다. LLM과의 대화는 메시지 객체들의 배열로 표현되고, 각 메시지는 역할(시스템·유저·어시스턴트)과 콘텐츠로 구성된다. OpenAI의 API는 다음과 같은 구조를 쓴다.

{
  "messages": [
    {"role": "system", "content": "당신은 기꺼이 도움을 주는 코딩 어시스턴트입니다..."},
    {"role": "user", "content": "파이썬에서 이진 트리를 어떻게 구현하나요?"},
    {"role": "assistant", "content": "다음은 이진 트리를 구현하는 방법입니다:..."},
    {"role": "user", "content": "지금 이런 에러가 발생하고 있습니다. TypeError: 'NoneType'..."}
  ]
}

이 구조를 몰라도 바이브 코딩은 할 수 있다. 다만 어떤 인터페이스(ChatGPT·클로드 코드·IDE 플러그인 등)를 쓰든, 그 이면에서 이런 JSON 데이터가 점점 커지다가 결국 콘텍스트 윈도 용량을 초과한다는 사실은 알고 있어야 한다. LLM은 대화가 종료되면 대개 이전 대화를 기억하지 못하므로, API를 호출할 때마다 대화 이력이 반드시 다시 들어가야 한다 — AI가 별도 메모리를 갖더라도, 결국 그 메모리에서 관련 콘텍스트를 꺼내 콘텍스트 윈도에 다시 채워 넣는 것은 마찬가지다. AI는 콘텍스트 윈도에 없는 정보를 알지 못한다.

2차함수적 비용. 그 결과 대화 객체는 턴이 진행될수록 점점 길어지고, 일관성을 유지하기 위한 콘텍스트를 계속 제공하다 보면 쓸 수 있는 토큰의 양은 점진적으로 줄어든다. 대화는 선형적으로 늘어나지만, 누적 토큰 비용은 턴 수가 늘어날수록 2차함수적으로(quadratically) 증가한다 — 첫 턴의 비용이 1이면 두 번째 턴은 이전(1)+새 대화(2)=3, 세 번째 턴은 1+2+3=6, n번째 턴까지의 누적 비용은 1+2+…+n = n(n+1)/2, 즉 O(n²)이다. 이는 울타리를 칠하는 화가가 새 구간을 칠하기 전에 이전에 칠한 모든 구간을 다시 칠해야 하는 상황과 같다 — 울타리가 길어질수록 화가는 매번 처음부터 다시 칠하느라 더 많은 시간을 쓰고, 실제로 앞으로 나아가는 속도는 점점 느려진다.

콘텍스트가 길어지면 추론도 흐트러진다. Fiction.liveBench 평가는 이야기가 길어질 때 모델이 이야기 전반을 토대로 추론할 수 있는지(예: 2장에서 한 약속을 기억하고 16장의 반전을 떠올린 뒤 마지막 질문에 답하기)를 테스트한다. 모델 대부분은 중요한 세부 사항을 놓치거나, 모든 정보를 동등하게 취급해 표면적 패턴에 기반한 추론을 하다가 마지막 질문에 제대로 답하지 못한다. 콘텍스트 윈도에 너무 많은 내용이 있는 상태에서 대규모 코드베이스에 대한 추론을 요청하면 정확히 같은 붕괴가 일어난다 — 간단해 보이는 '후속 질문' 하나도 비용이 많이 들 수 있고, 두 번째 턴이 아니라 200번째 턴에서 던지는 질문이라면 더욱 그렇다.

해결책 — 가차 없는 제거. 콘텍스트가 쌓이며 생기는 추론 붕괴의 해결책은 가차 없는 콘텍스트 제거 또는 정제다. 가능하면 언제든 새 대화를 시작하고, 그럴 수 없다면 도구로 콘텍스트를 최대한 압축한다. AI가 잘못된 방향으로 가고 있다면 문제가 시작된 지점으로 되돌아가 다시 시작하는 것이 좋다 — 게임 중간 저장처럼, 코딩 에이전트 대다수가 제공하는 체크포인팅 기능을 이럴 때 적극적으로 쓴다.

4. 콘텍스트 포화의 위험성

생일 파티 만찬을 준비한다고 가정해 보자. 주방엔 "이 파티에 오는 모든 사람은 심각한 글루텐 알레르기가 있으니 밀가루는 절대 쓰지 말라"고 분명히 지시해뒀다. 처음 몇 요리는 주문대로 잘 나온다. 그러나 주방이 바빠지고 추가 지시가 쌓이면서, 대략 열 번째 요리쯤 부주방장들이 아무 생각 없이 밀가루를 집어 들기 시작한다 — 중요한 지시를 완전히 잊은 채로.

AI의 콘텍스트 윈도가 가득 찼을 때 벌어지는 일이 정확히 이렇다. 콘텍스트가 차오르면 AI의 성능이 점진적으로 떨어지는 것이 아니다. 어느 순간 절벽처럼 급격히 무너져 내린다. 2024년에 진행된 연구는 이 붕괴의 원인을 설명한다 — 모델 대부분은 공식적으로 홍보하는 최대 콘텍스트 용량과 무관하게, 실제로는 훨씬 이른 시점(약 3000토큰 부근)부터 추론 능력의 저하가 시작된다. 이를 콘텍스트 포화라 부르며, 포화 상태의 AI는 다음과 같은 이상행동을 보인다 — ① 일관성이 떨어지는 응답을 생성한다 ② 불과 30초 전에 언급한 핵심 정보를 잊어버린다 ③ 서로 모순되는 답변을 하며 사용자를 빙빙 돌린다 ④ 대문자로 강조한 명시적 지시조차 무시한다.

참고 — 직접 실험해 보는 법. ChatGPT 같은 챗봇에서 대화를 시작해 "앨리스는 보스턴에 사는 의사이며 파란색 렉서스를 운전한다" 같은 사실 몇 가지를 먼저 입력한다. 그다음 메시지에 위키백과 문서 같은 긴 텍스트를 계속 덧붙이면서, 중간중간 앨리스에 대해 다시 질문해 본다. 콘텍스트 윈도가 채워질수록 모델이 앨리스에 대한 정보를 잊거나, 스스로 모순된 사고를 하거나, 확신 없는 답변을 하는 모습(앨리스가 변호사가 됐다고 말하거나, 어디 사는지 모른다고 답하는 식)을 보게 된다.

클로드 소네트 3.7 사례. 콘텍스트 포화는 바이브 코딩 세션을 완전히 망가뜨릴 수 있다. 스티브의 팀은 코딩 에이전트에게 "절대 ps aux를 실행하지 마라. 그것은 콘텍스트 윈도를 과부하시킨다"라고 명시적으로 지시했다(ps aux는 시스템 전체 프로세스를 출력하는 명령이라 결과가 매우 많고, 그대로 콘텍스트에 담기면 토큰을 대량 소모해 콘텍스트 포화를 유발한다). 처음엔 지시를 잘 따르던 코딩 에이전트가, 대화가 콘텍스트 윈도 한계의 50% 수준에 도달하자 필터를 적용한 ps 명령을 시도했다. 그 명령이 실패하자 곧바로 금지해뒀던 ps aux를 실행했고, 세션은 크래시가 났다. 이 경험이 준 다소 냉정한 교훈은 이것이다 — AI의 클립보드에 올라간 것이 많아질수록, AI는 더 멍청해진다.

5. 출력 콘텍스트 윈도의 한계

지금까지는 셰프의 클립보드, 즉 입력 콘텍스트 윈도를 이야기했다. 그러나 콘텍스트 용량을 계산할 때는 또 하나의 요소를 고려해야 한다 — AI가 한 번에 돌려줄 수 있는 출력의 양이다. 서빙 트레이의 크기를 상상하면 이해가 쉽다. 실제 클립보드에 비유하면, AI가 한 번에 출력할 수 있는 양은 우표 사이즈 정도다.

이 출력량을 출력 콘텍스트 윈도라 부르며, AI가 단일 응답에서 생성할 수 있는 최대 토큰 수를 뜻한다. 이 책을 쓰는 시점 기준, 프런티어 모델 대부분은 한 번에 약 4000~8000토큰 정도만 반환할 수 있다. 책 집필 시점에서 제미나이 2.5 프로가 6만 4000토큰이라는 예외적인 수치를 보여줬다.

출력 콘텍스트 윈도는 AI에게 'potato'라는 단어를 100만 번 출력해 달라고 요청하거나, 한 시간짜리 회의 녹취록을 끊지 말고 한 번에 텍스트로 옮겨 달라고 요청해 보면 직접 확인할 수 있다. 처음엔 제대로 응답하는 듯하지만 결국 출력 공간 부족으로 멈춘다 — 운이 좋으면 AI가 "계속할까요?"라고 묻고 이어서 출력을 재개한다(서버가 트레이를 하나 더 들고 나오는 것과 같다). 클로드 아티팩트와 제미나이 캔버스처럼 여러 차례 생성된 출력이 누적되며 큰 코드가 하나의 작업 공간에 쌓이는 환경에서는 이 현상을 쉽게 볼 수 있다.

출력 콘텍스트 제한은 일상적인 바이브 코딩에도 실제 영향을 미친다. 입력 클립보드에 아무리 정교하게 콘텍스트를 담아 두었어도, AI는 출력 용량을 초과하는 수천 줄짜리 코드베이스를 한 번에 답할 수 없다. 이것이 바로 아직 AI에게 "운영체제를 만들어 줘"라고 요청해도 완성작을 한 번에 받아 볼 수 없는 이유다. 헤드 셰프로서 야심 찬 요리를 하고 싶다면, 더 작고 관리 가능한 코스나 요리 수준으로 작업을 쪼갠 뒤 요청해야 한다 — 출력 한계 안에 들어오는 작업 단위로 분리하라는 뜻이다. 바로 이 지점에서 FAAFO의 이상(야심)이 주방의 물류 문제인 출력 콘텍스트 제한과 맞닿는다.

6. 클립보드에 무엇을 올릴 것인가 — 콘텍스트가 왕이다

콘텍스트 윈도는 소중하지만 쉽게 넘칠 수 있다. AI 파트너에게는 문제를 해결하는 데 필요한 정보만 제공해야 한다 — 즉 무엇을 클립보드에 올릴지 결정해야 한다.

"콘텍스트가 왕이다"(context is king)라는 말은 마케팅부터 역사 해석까지 여러 분야에서 통용되는 원칙이며, 바이브 코딩에도 그대로 적용된다. 웹 개발·오픈소스·데이터 저널리즘 분야의 저명 인사 사이먼 윌리슨은 이를 이렇게 표현했다 — "콘텍스트가 왕이다. LLM에서 좋은 결과를 얻는 데 필요한 기술 대부분은 콘텍스트 관리에서 나온다."

유용한 콘텍스트는 현재 작업을 명확히 비추는 모든 것을 포함한다 — 코드 조각 일부가 아니라 작업 중인 모듈의 전체 소스 파일, 터미널에서 그대로 복사한 에러 메시지와 스택 트레이스, LLM이 그대로 따라 할 수 있는 예제(인콘텍스트 학습), 데이터베이스 스키마나 샘플 데이터, 연동 중인 외부 서비스의 API 문서, package.json·pom.xml·requirements.txt 같은 빌드·의존성 정보, 이미 시도했으나 실패한 변경 사항을 보여주는 깃 diff, 기대 동작을 보여주는 테스트 케이스, 애플리케이션 동작에 영향을 미치는 연관 설정 파일, 참고할 만한 브랜치나 저장소, 커스텀 데이터·백엔드에 접근하게 해주는 MCP 서버 등이다.

제공하는 콘텍스트의 품질은 AI 어시스턴트의 유효성에 직접 영향을 준다. 프로젝트가 커질수록 관련 파일을 수동으로 복사해 붙이는 작업은 번거로워지는데, IDE에 통합된 코딩 어시스턴트는 필요한 콘텍스트를 자동으로 수집해 전달해 준다. 코딩 에이전트도 숙련된 셰프처럼 스스로 콘텍스트를 찾아내는 데 능숙하지만, "인증 모듈은 /src/auth에 있다"처럼 직접 방향을 짚어 주면 소중한 시간과 토큰이 절약된다. 그리고 가능한 한 MCP로 더 많은 실시간·동적 데이터 소스를 연결해 두는 편이 좋다 — 코딩 에이전트는 가치 있는 정보를 스스로 찾아내는 데 능하지만, 접근 권한이 없으면 그 능력을 발휘하지 못한다.

7. 집중형 콘텍스트 ↔ 포괄형 콘텍스트

AI와의 모든 상호작용마다 얼마나 많은 콘텍스트를 제공할지 결정해야 한다. 콘텍스트 스펙트럼은 단일 함수 디버깅을 위한 코드 조각·에러 메시지 같은 최소 정보부터, 시스템 구조·프로젝트 이력·코딩 철학 전반을 아우르는 포괄적 배경 지식까지 다양하다. 기존 시스템과 매끄럽게 통합되어야 하는 새 마이크로서비스 설계를 맡긴다면 넓은 콘텍스트가 필요하다 — 순간순간의 판단이 결과물의 품질을 좌우한다.

집중형 콘텍스트. 당면 작업에 필요한 최소한의 콘텍스트만 제공하는 전략이다. 아직 구현을 시작하지 않은 함수의 시그니처, 버그가 있는 코드의 라인 정보, 해석이 필요한 특정 에러 메시지 등이 여기 해당한다. 더 넓은 시스템을 이해할 필요가 없는 '리프 노드' 작업, 즉 독립적이고 국소적인 문제에 잘 작동한다. 클립보드를 깔끔하게 유지하면서 콘텍스트 포화 위험을 피할 수 있고, 속도·민첩성·빠른 반복·빠른 피드백 루프 등 FAAFO에 기여하는 장점이 많다. 진은 비디오 발췌 툴 프로젝트에서 이 전략을 핵심으로 채택해, 각 단계마다 AI에게 매우 구체적으로 지시했다.

포괄형 콘텍스트. 모듈급 코드 덩어리, 프로젝트 문서, 코딩 스탠더드, 설계 결정 사항, 연관 이슈와 토론 등 방대한 정보를 한꺼번에 제공하는 전략이다. 어떤 콘텍스트를 넣을지 선별하는 것보다 대개 훨씬 쉽기 때문에 인기가 있다 — 가진 정보를 한꺼번에 던져 넣으면 된다. 저자들은 이 책의 초안을 LLM으로 작성하며, 사소한 편집에도 매번 원고 전체를 프롬프트에 포함하는 실험을 했다. 결과는 전반적으로 더 뛰어났다 — 두 저자의 톤을 AI가 일관되게 맞췄고, 명시적으로 연결하지 않았던 장들 사이의 연관성까지 발견해 줬다. 포괄형 전략은 시스템 전반의 관점이 필요할 때(설계 결정, 대규모 리팩터링, 새 코드와 기존 컨벤션의 조화), 그리고 '전체 작업 그래프' 수준의 작업을 할 때 탁월하다. 코드베이스가 크지 않은 신규 프로젝트나 토큰을 많이 쓰지 않는 독립 모듈 같은 작은 시스템에서도 잘 작동한다.

8. 어떤 전략을 사용할까 — 대규모 코드베이스 다루기

저자들은 보통 집중형 콘텍스트로 AI와의 상호작용을 시작한다. 머릿속엔 크고 야심 찬 작업이 있어도, AI에게 한 번에 맡기기보다는 사람이 먼저 작은 작업으로 나눈 뒤 각 작업에 필요한 최소한의 정보만 전달하는 방식을 선호하기 때문이다.

반면 안드레이 카르파티 박사는 작은 코드베이스에서 작업할 때 포괄형 콘텍스트 사용을 권한다 — "관련된 모든 것을 콘텍스트에 집어넣어라. 대규모 프로젝트에서는 시간이 꽤 걸릴 수 있다. 그렇지만 프로젝트가 충분히 작다면 그냥 전부 넣어라"라며, files-to-prompt 유틸리티로 모든 소스 파일을 AI에게 제공하라고 조언했다.

저장소 전체를 넘겨도 콘텍스트 윈도 안에 여유 공간이 넉넉하면 AI에게 전체 그림을 제공하는 것이 효과적이다. 문제는 코드베이스가 콘텍스트 윈도 한계를 넘어설 때다 — 너무 많은 내용을 억지로 밀어 넣으면 콘텍스트 포화를 겪고, AI는 세부 사항을 잊거나 명시적 지시를 무시하기 시작한다.

대규모 코드베이스 — 요약 문서. 저자들은 요약 문서를 만드는 방식으로 원하는 성과를 얻었다. 요약 문서는 프로젝트의 클리프노트 역할을 한다 — AI로 각 모듈의 개요를 생성하고 핵심 아키텍처 결정과 공통 패턴을 정리하면, 이 요약 문서는 AI가 작업 내용에 따라 선택적으로 쓸 수 있는 핵심 콘텍스트 조각이 된다. 자잘한 정보로 수셰프에게 부담을 주지 않으면서도, 주방 운영의 본질을 담은 압축 레시피북으로 대규모 주방을 지휘할 수 있다.

더 큰 규모 — RAG. 더 큰 코드베이스에서는 RAG(검색 증강 생성)가 가장 든든한 도구다. RAG는 AI를 위해 특수 제작된 검색 엔진처럼 작동해, 필요할 때 관련 정보 조각을 끌어온다. RAG나 코드베이스 인덱스 없이 대규모 코드베이스를 다루면, 코딩 에이전트는 grep·cat·sed 같은 유닉스 도구로 "쓰레기통을 뒤지는 쥐"처럼 파일과 디렉터리를 헤맨다 — 결국 필요한 코드를 찾긴 하겠지만, 사전 인덱싱 없이 이 과정을 지켜보는 것은 고통스럽다. 그래서 MCP 등을 통해 코딩 에이전트에게 RAG 시스템 접근 권한을 부여하라고 저자들은 권한다.

참고 — 아직 답이 정해지지 않은 논쟁. 저자들도 어떤 접근이 가장 잘 작동하는지 확실히 알아내지 못했다고 인정한다. 클로드 코드 팀은 내부 실험에서 RAG가 오히려 코딩 성능을 떨어뜨리는 경우도 있었다고 밝혔다. 클로드 코드의 기술 리더 보리스 체르니는 "에이전트 기반 검색이 RAG보다 훨씬 뛰어났다. 이는 놀라운 결과였다"고 말했다. 모든 방식에는 트레이드오프가 있고, 한 프로젝트에서 잘 통하는 방법이 다른 프로젝트에서는 전혀 효과가 없을 수 있다 — 결국 계속 실험하는 것이 중요하다.

9. 결론 — 다섯 가지 핵심 실천 사항

AI의 클립보드, 즉 콘텍스트 윈도를 관리하고 깔끔하게 유지하는 것은 AI와의 모든 상호작용에 핵심적인 역할을 한다. 잘 관리하면 AI 파트너는 놀라운 요리 실력을 발휘하지만, 잘못 관리하면 글루텐 프리 만찬에 밀가루 음식을 서빙하는 악몽을 마주하게 된다 — 콘텍스트 윈도가 차면 찰수록 AI는 점점 더 멍청해진다. 효과적인 콘텍스트 관리가 까다로운 이유는, 어떤 때는 콘텍스트를 많이 줄 때 AI가 일을 더 잘하고, 다른 때는 정반대 현상이 일어나기 때문이다.

작업 공간을 관리할 때 기억해야 할 핵심 실천 사항은 다섯 가지다.

• 콘텍스트 윈도를 항상 주시하기 — 중요하지 않거나 관련 없는 데이터로 콘텍스트 윈도를 채우지 않는다.
• 콘텍스트 포화를 조기에 인지하기 — AI가 산만하게 응답하기 시작하면, 부담을 줄여 주거나 새 대화를 시작한다.
• 집중형 콘텍스트와 포괄형 콘텍스트를 구분해서 쓰기 — 문제의 범위에 따라 다른 전략을 쓴다.
• 콘텍스트 관리 도구를 알아보기 — 요약 문서, RAG, 에이전트 기반 접근 방식으로 크고 복잡한 코드베이스를 다룬다.
• 자신의 직감을 신뢰하기 — AI가 흔들리고 있다고 느껴지면 한발 물러서서 클립보드에 무엇이 올라가 있는지 다시 점검한다.

이제 AI의 도마를 관리하고 작업 공간을 깔끔하게 유지할 준비가 됐으니, 다음 장(11장, 보상 함수 하이재킹)에서는 바이브 코딩의 또 다른 교묘한 측면 — AI가 왜 체계적으로 요령을 피우고 질 낮은 결과물을 만들어내는지, 그리고 이 문제를 극복하는 방법 — 을 살펴본다.

핵심 개념 정리

실무 체크리스트

• [ ] 지금 콘텍스트 윈도에 올라간 정보 중, 이번 작업과 무관한 것을 그대로 남겨 두고 있지는 않은가?
• [ ] AI가 산만하게 답하거나 방금 한 지시를 잊기 시작했는데도, "공식 최대 용량엔 아직 여유가 있다"며 무시하고 있지 않은가?
• [ ] 리프 노드 수준의 국소적 버그 수정에, 프로젝트 전체 문서·코드를 통째로 넣는 포괄형 콘텍스트를 쓰고 있지 않은가?
• [ ] 설계 변경·대규모 리팩터링처럼 시스템 전반의 관점이 필요한 작업에, 집중형 콘텍스트로 단편적인 지시만 주고 있지 않은가?
• [ ] 대화가 막다른 길로 들어섰다고 느낄 때, 새 대화를 시작하거나 체크포인트로 되돌아가는 대신 같은 대화를 억지로 이어가고 있지 않은가?
• [ ] 한 번에 수천 줄짜리 결과물을 요구하면서, 출력 콘텍스트 윈도 한계를 감안해 작업을 더 작은 단위로 쪼개지 않고 있지는 않은가?
• [ ] 대규모 코드베이스에서 에이전트가 grep·cat으로 파일을 헤매게만 두고, 요약 문서·RAG·MCP 같은 도구로 방향을 짚어 주지 않고 있는가?
• [ ] "콘텍스트를 많이 줄수록 항상 더 좋다"고 가정하며, 상황에 따라 최소 정보만 주는 편이 더 나은 경우를 놓치고 있지 않은가?

연습문제

1. 유형: 판단. 대화가 시작된 지 얼마 안 돼 콘텍스트 윈도 사용량이 공식 최대치의 일부에 불과한데도 AI가 지시를 무시하기 시작했다. "아직 윈도가 안 찼으니 문제없다"는 동료의 판단을, 이 장 §4의 콘텍스트 포화 개념을 근거로 반박하라.
2. 유형: 분석. 신규 소규모 프로젝트와 대규모 레거시 시스템 모두에 "관련된 모든 파일을 통째로 던져 넣는" 포괄형 전략을 똑같이 적용하려 한다. §7·§8을 근거로 이 결정의 위험을 분석하라.
3. 유형: 비교. 집중형 콘텍스트와 포괄형 콘텍스트 전략을 적합한 작업 유형·핵심 장점 중심으로 비교하고, 리프 노드 작업에 포괄형 콘텍스트를 쓰면 어떤 비효율이 생기는지 설명하라.
4. 유형: 실무 시나리오. 대화가 200번째 턴에 이르렀고, AI가 30초 전에 말한 내용도 잊고 모순된 답을 하기 시작했다. §3·§4의 개념(2차함수적 비용·콘텍스트 포화·체크포인팅)을 근거로 무엇을 어떤 순서로 해야 하는지 판단하라.
5. 유형: 판단. "대규모 코드베이스에는 RAG를 도입하면 코딩 성능이 항상 좋아진다"고 주장하는 동료가 있다. §8의 클로드 코드 팀 사례를 근거로 이 주장의 문제를 지적하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-14) — 이 장이 설명한 콘텍스트 윈도의 원리(토큰·포화·2차함수적 비용)와 관리 전략은 그대로 유효하다. 구체적인 규모 하나와 인용 하나가 그 뒤로 갱신됐다.

• 콘텍스트 윈도 규모, "예외"에서 "여러 모델의 표준"으로. 이 장은 프런티어 모델의 콘텍스트 윈도를 20만~100만 토큰으로 소개했다. Anthropic 공식 문서에 따르면 이제 여러 최신 모델이 채팅·API 양쪽에서 100만 토큰 윈도를 지원한다 — 이 장이 예로 든 규모의 상한이 한 모델만의 예외가 아니라 여럿의 표준 사양이 됐다. 이 장이 언급한 라마 4의 1000만 토큰급 규모는 여전히 업계에서 가장 큰 축에 속한다.
• RAG 대 에이전트 기반 검색 — 원저자의 관찰은 계속 인용되고 있다. §8이 소개한 클로드 코드 기술 리더 보리스 체르니의 관찰("에이전트 기반 검색이 RAG보다 뛰어났다")은 본인이 직접 밝힌 내용이며(Boris Cherny, X), 이후에도 대규모 코드베이스를 다루는 다른 개발팀들의 비슷한 보고가 이어지고 있다. 다만 이 장이 이미 밝혔듯 "어떤 접근이 가장 잘 작동하는지"는 여전히 프로젝트마다 다른, 계속 실험 중인 영역이다.
• Fiction.liveBench, 여전히 갱신되는 활성 벤치마크. 이 장이 인용한 장문 추론 평가 Fiction.liveBench(Epoch AI의 벤치마크 소개)는 새 모델이 나올 때마다 계속 갱신되고 있다 — 콘텍스트가 길어질수록 추론이 흐트러진다는 이 장의 진단은 지금도 이 벤치마크의 핵심 관찰로 남아 있다.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-14)

• 콘텍스트 윈도 공식 문서 — Context windows (Claude Platform Docs)
• 유료 플랜별 콘텍스트 윈도 크기 — Anthropic 고객센터
• MCP 공식 사이트 — Model Context Protocol
• 장문 추론 벤치마크 — Fiction.liveBench · Epoch AI의 벤치마크 소개
• RAG vs 에이전트 기반 검색 발언 원문 — Boris Cherny, X

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) §4는 "콘텍스트가 차오르면 AI의 성능이 점진적으로 떨어지는 것이 아니라 어느 순간 절벽처럼 급격히 무너진다"고 밝힌다. 2024년 연구에 따르면 이 붕괴는 공식 최대 용량과 무관하게 실제로는 훨씬 이른 시점(약 3000토큰 부근)부터 시작된다. 따라서 "아직 공식 최대치의 일부만 썼으니 안전하다"는 판단은 붕괴가 시작되는 실제 임계치가 광고된 최대 용량보다 훨씬 낮다는 사실을 놓친 것이다.
2. (문제 2 정답) §7은 포괄형 콘텍스트가 "코드베이스가 크지 않은 신규 프로젝트나 작은 규모의 시스템에서 잘 작동한다"고 명시한다. 반대로 §8은 "코드베이스가 콘텍스트 윈도 한계를 넘어서면" 문제가 생긴다고 경고한다. 대규모 레거시 시스템에 전체를 통째로 넣으면 콘텍스트 포화로 AI가 세부 사항을 잊거나 지시를 무시하기 시작하므로, 규모에 따라 요약 문서·RAG 같은 다른 도구로 전환해야 한다.
3. (문제 3 정답) §7에 따르면 집중형 콘텍스트는 최소 정보만 제공해 속도·민첩성이 뛰어나고 리프 노드(국소적) 작업에 적합하다. 포괄형 콘텍스트는 방대한 정보를 한꺼번에 제공해 시스템 전반의 일관성을 얻지만 선별 부담이 적은 대신 콘텍스트를 많이 소모한다. 리프 노드 작업에 포괄형을 쓰면, 필요 없는 정보로 콘텍스트 윈도를 불필요하게 채워 포화 위험을 키우고 속도 이점을 잃는다.
4. (문제 4 정답) §3은 200번째 턴 같은 후반부 질문일수록 누적 비용이 2차함수적으로 커진다고 설명하고, §4는 지금 겪는 정보 망각·모순된 응답이 콘텍스트 포화의 전형적 증상이라 밝힌다. §3의 해법(가차 없는 제거)에 따라, 먼저 문제가 시작된 지점을 파악해 체크포인트로 되돌아가거나, 그럴 수 없다면 지금까지의 핵심만 요약해 새 대화를 시작해야 한다 — 같은 콘텍스트를 그대로 쌓아 두고 대화를 이어가는 것은 §4가 경고하는 상황을 악화시킬 뿐이다.
5. (문제 5 정답) §8은 "클로드 코드 팀은 내부 실험에서 RAG가 오히려 코딩 성능을 떨어뜨리는 경우도 있었다"고 밝히며, 보리스 체르니의 말("에이전트 기반 검색이 RAG보다 훨씬 뛰어났다")을 인용한다. 이어 "모든 방식에는 트레이드오프가 있고, 한 프로젝트에서 잘 통하는 방법이 다른 프로젝트에서는 전혀 효과가 없을 수 있다"고 명시한다. 따라서 "RAG가 항상 좋아진다"는 주장은 이 장이 제시하는 실제 반례와, 정답이 프로젝트마다 다르다는 결론에 어긋난다.